Accept an expected consumption of zero - #61

The problem

expectedConsumption cannot express "this limit takes part in the evaluation, but this call spends nothing of it".

When a caller provides expectedConsumption, evaluateFeature requires a value for every limit involved in the feature's expression, or it refuses the call:

Please note that if you provide an expectedConsumption for any limit, you must provide it for all limits involved in that feature's evaluation.

So the only value a caller can give for a limit they are not spending is 0. Two falsy checks in featureEvaluation.ts rejected exactly that, and reported it with the message meant for a caller who forgot the limit entirely.

The second check is the wider bug: it tests the sum, not the input, so it also refuses an ordinary positive consumption whenever the current usage level is still 0 — the state of every contract on its first call, and of every renewable limit right after it resets.

// _buildSuccessResult
const updatedUsageLevel = _updateUsageLevel(subscriptionContext[limitKey], expectedConsumption[limitKey]);
if (!updatedUsageLevel) {          // 0 + 0 === 0, and 0 is falsy
  return _createErrorResult('INVALID_EXPECTED_CONSUMPTION', ...);
}

// _updateUsageLevel
if (!expectedConsumption) {        // cannot tell 0 from undefined
  return undefined;
}

Reproduction

A feature whose expression involves one limit, evaluated with simple: false:

The first row is the "check without charging" case — asking whether an action would be allowed. The second is the same request against a contract that has not consumed anything yet. Neither has anything to do with a missing value, which is what the caller is told.

This also affects any feature whose expression involves several limits where only some are actually spent: the caller must name them all, and the ones that cost nothing can only be declared as zero.

The change

Two lines in api/src/main/utils/feature-evaluation/featureEvaluation.ts:

• _updateUsageLevel distinguishes an absent value from zero: expectedConsumption === undefined || expectedConsumption === null instead of !expectedConsumption.
• _buildSuccessResult checks the returned value for undefined instead of for falsiness, so a computed usage level of 0 is a result, not a failure.

The genuinely-missing case is unchanged: a limit absent from expectedConsumption still yields INVALID_EXPECTED_CONSUMPTION, and the separate throw in evaluateFeature that guards the write path is untouched.

Verification

New file api/src/test/feature-evaluation.zero-consumption.test.ts — 8 tests, driving the public evaluateFeature rather than the private helpers:

✓ src/test/feature-evaluation.zero-consumption.test.ts (8 tests)
  Tests  8 passed (8)

Each of the two source changes was reverted independently to confirm the tests are load-bearing: without the _buildSuccessResult fix, 2 of the 8 fail; without the _updateUsageLevel fix, 3 fail.

The existing suite for this module is unaffected:

✓ src/test/feature-evaluation.test.ts (26 tests)
  Tests  26 passed (26)

npx tsc --noEmit is clean.

Scope

Two lines plus a test file. No API shape, no schema and no persisted data changes; a request that worked before still works, and the newly accepted values previously produced an error rather than a different result — so nothing that currently succeeds changes behaviour.